Summary

readRecord() in grpcreplay/binary_format.go reads size as a raw uint32
from the replay file and passes it directly to make([]byte, size) with no
bounds check. A crafted 13-byte .grpc_replay file can trigger a 4 GB
allocation in any program that calls grpcreplay.NewReplayer() on an
attacker-supplied file.

Vulnerable code (before this fix)

func (r *binaryReader) readRecord() ([]byte, error) {
    var size uint32
    binary.Read(r.r, binary.LittleEndian, &size)
    buf := make([]byte, size) // no bounds check: up to 4 GB

Trigger file (13 bytes)

Standalone reproducer output (size capped at 512 MB to avoid crashing the host):

[*] Crafted replay file: 13 bytes
[*] Encoded size: 0x20000000 (512 MB)
[*] TotalAlloc before parse: 0 MB
[*] TotalAlloc after parse:  512 MB (delta: +512 MB)
[!] VULNERABLE: 512 MB allocated from a 13-byte replay file.

Fix

Add maxRecordSize = 64 MiB constant (gRPC's own default max message size
is 4 MiB; 64 MiB is a generous upper bound) and reject records that exceed
it before allocation.

Testing

TestOversizeRecord in grpcreplay_test.go verifies that readRecord()
returns an error for an oversized size field without causing a large allocation.